USB Communication

The Human Interface Device (HID) class is used to communicate with the device. The main benefit is that there are no drivers needed.
The drawback is low communication speed, but this is OK for this use case as there is not much data transmitted.
Note that the HID protocol differentiates between input reports, output reports and feature reports.
Input reports (e.g. endpoint 1) are usually periodic, i.e. the operating system of the master (e.g. Windows) will poll the input report at the interval defined in the device's configuration descriptor.
It is also possible to read the input report via a control request on demand (e.g. via endpoint 0), but due to the periodic nature of the input report, this can lead to bandwidth and buffering issues.
Indeed, while reading input reports via control requests worked in a C# prototype, it didn't work via the Java HID API.
As a workaround, I decided to (ab-)use the feature report to communicate with the device instead. The input report is just used for a small period message which contains the current state and engine speed.
So the size of the (periodic) input report is limited to 3 bytes (8bit state followed by 16bit engine speed), while the size of the feature report is set to 32 bytes.

Protocol

The communication is always initiated by the master (PC) and starts with an 8bit command. The following 31 bytes can be used for data belonging to the command.
The device always answers with ACK|command (ACK = 0x80 is ORed with command), followed by a status (0: OK else specific fault status code). The following 30 bytes are command specific (i.e. containing requested data).
Transferring data from/to the four channels requires channel specific commands. The 2bit channel information is then coded into the two lowermost bits of the command.
E.g. INIT_READ_CH0 is 8 (8|0) and INIT_READ_CH3 is 11 (8|3).
Note that 16bit and 32bit values are transferred little endian (lowest byte first, highest byte last).

Fault status codes

Commands

Command details

Get Revision

Write data to channel X

Read data from channel X

Start output signal creation

Set engine speed

Get engine speed

Write Gradient

Read Gradient

Start Gradient

Stop Gradient

Write NVRAM

Read NVRAM

Clear NVRAM

Get NVRAM state

Set PWM channel

Get PWM channel

Update Modes

Sets the modes for all four channels at once.

Set BiDir Setup

Sets new device configuration for bidirectional crank simulation.

PC sends
    SET_BIDIR_SETUP (U8), REV_ENABLE (U8), BIDIR_ENABLE (U8), ACTIVE_EDGE (U8), FWD_PERIOD (U32), REV_PERIOD (U32)

Device answers
    SET_BIDIR_SETUP|ACK (U8), FAULT_OK (U8)

REV_ENABLE enabled (1) or disables the possibility of negative engine speeds (inverted rotation direction)
BIDIR_ENABLE enables (1) or disables (0) the bidirectional simulation for channel 0.
ACTIVE_EDGE defines falling edge (0) or rising edge (1) as active edge (i.e. falling edge means the active period will be low)
FWD_PERIOD defines the active period for forward rotation (in timer ticks)
REV_PERIOD defines the active period for reverse rotation (in timer ticks)

Get BiDir Setup

Create glitches

Create glitches by pulling the masked channel to the given direction for a certain time (repeat with period)

PC sends
    SET_GLITCHES (U8), CH_ENABLE_MASK (U8), CH_POLARITY_MASK (U8), COUNT (U8), DURATION (U32), PERIOD (U32)

Device answers
    SET_GLITCHES|ACK (U8), FAULT_OK (U8)

CH_ENABLE_MASK: set channel bit (1<<ch) to 1 to create a glitch on the channel
CH_POLARITY_MASK: pull enabled channel low (0) or high (1)
COUNT: repeat the glitch creation count times.
DURATION: duration of one glitch in timer ticks
PERIOD: interval between two glitches (from start to start) in timer ticks - must be larger than DURATION

Back to main page